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1 METHOD AND SYSTEM FOR VALIDATION OF SERVICE CONSUMERS 

2 FIELD OF THE INVENTION 

3 The field of the invention is that of providing services in distributed computing and 

4 internetworked environment, in particular a system and method for service Providers to 

5 validate or qualify the ability of service Consumers to properly use their services. 

6 BACKGROUND OF THE INVENTION 

7 This invention concerns the technical problems associated with connecting computer 

8 programs together so that, for example, one program can request a service from a second 

9 program and the second program can effectively respond and provide that service. 

10 Specifically this invention concerns the problem of how the program providing the 

1 1 service - hereafter the Provider - can be sure that the program invoking the service - 

12 hereafter the Consumer - knows how to use the service correctly so as to obtain the 

13 desired result. 

1 4 Connecting Computer Programs Together 

1 5 The problem of connecting computer programs together as envisaged here has long been 

16 known to present severe technical difficulties. Many methods have been invented to 
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1 produce such connections. One of the earliest approaches is still known today as "screen 

2 scraping" in which the Consumer program emulates a computer terminal that would 

3 normally provide the input and output channels for the Provider program. During the 

4 1980s the Remote Program Call (RPC) method emerged in which the Consumer program 

5 uses a dedicated network function to pass messages between the Consumer and Provider 

6 programs. In the late 1980s and 1990s object oriented programming methodology 

7 introduced the ideas of an interface definition, specifying how a given object can be 

8 bound into the main program, a distributed object framework that can relay messages to 

9 remote objects, and an object resource broker that can find objects that exactly match a 

10 required interface specification (e.g. CORBA, RMI). A trend along this path is towards 

1 1 later and more flexible binding. For example, the screen scraping method and the RPC 

12 method depend on code bindings that are produced at compile time and are also brittle, 

1 3 meaning that even minor changes in the operations of the Consumer or Provider will 

14 cause the methods to fail. The object-oriented approaches support run-time binding 

1 5 mechanisms, but are also brittle in that they require exact matches of the interface 

16 specifications. 

1 7 For these reasons of early binding and brittleness, the Consumer-Provider model of 

1 8 distributed computing has been difficult to implement. Where it has been used, for 

19 example, in Enterprise Resource Planning (ERP) systems, it has tended to be based on 

20 proprietary interface specifications and to rely on detailed interface design and testing to 

21 ensure correct operation of the Consumer-Provider relationship. Such systems are hard 

22 and expensive to develop and to modify and consequently have been limited in their 

23 deployment to large enterprises. They are also inherently closed because of the 

24 proprietary nature of the protocol details. On the other hand the Worldwide Web, which 

25 depends on a single, publicly-specified interface protocol (HTTP) built on top of the 

26 public Internet Protocol has demonstrated the value of flexible, dynamic access to 

27 millions of Providers and consequently hundreds of millions of instances of the 

28 connection of a Web browser (Consumer) to a Web server (Provider) exist and are 

29 established and canceled at the click of a button. The ability to establish and cancel 
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1 connections between Consumer and Provider programs with the same ease as surfing the 

2 Web is a highly sought-after goal. 

3 Computer Programs as Business Processes 

4 The advent of e-business during the 1990s introduced the model of an enterprise as a 

5 collection of business processes. Each business process has a Provider interface into 

6 which Consumers submit requests for services - for example by completing a paper form 

7 - and a Consumer interface which receives the service or notification of the dispatch of 

8 the service - for example a shipping document. These business processes are increasingly 

9 implemented or shadowed as computer applications. Much of the work involved in 

10 implementing e-business has been in integrating these applications together to form 

1 1 business process networks. The idea of modeling an enterprise as a network of business 

12 processes has been extended to the interconnection of enterprises and this lead to the idea 

13 of providing a flexible, dynamic binding method to enable an enterprise to buy services 

14 from a Provider and to change that service Provider at will. This idea evolved into Web 

15 Services and subsequently evolved backwards into a general method of Enterprise 

16 Application Integration. A community of software developers, lead by Ariba, IBM, and 

17 Microsoft has developed a set of open industry standards for the processes of discovering 

1 8 service Providers that meet a set of functional requirements, with provision for fuzzy 

19 matching, for dialog between a Consumer and Provider on the methods of interaction, 

20 and a business transaction method that ensures payment for services delivered. While 

21 Web Services are one of the main application areas for this invention, the invention is not 

22 limited in any way to being implemented only through the Web Services standards and 

23 could be implemented through other public or proprietary interface methods. 

24 Service Oriented Architectures (SOAs) 

25 Today's typical enterprise depends on distributed systems linked via networks to perform 

26 many if not most routine computing tasks. For instance, when the typical bank creates a 
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1 new account, entries may be created in a variety of distinct databases. In particular, one 

2 database may hold the customer identification number and tax information, another 

3 database may hold the customer mailing information and another database may hold 

4 account balance information. Furthermore, many other applications usually employ these 

5 same databases and have their own access methods and means for updating information. 

6 In spite of numerous industry efforts to reign in the complexity of such systems, this 

7 approach has led to systems that are expensive to maintain and tend to be fragile. Perhaps 

8 the most undesirable characteristic is that small (seemingly harmless) changes in any one 

9 of the distributed systems may lead to unexpected and unpredictable consequences for 

10 applications that had unknown dependencies on the part that was modified. Indeed, any 

1 1 change to operating systems requires careful research into known dependencies followed 

12 by expensive change planning followed by a through and broad system testing. 

13 A concept referred to as service oriented architecture (SO A) is currently popular within 

14 the computing industry as a way to reduce the cost of designing, creating and managing 

15 such distributed systems. The fundamental idea is to divide the computing tasks into 

16 discrete blocks that can be addressed individually, and then later combined into higher 

17 level functional blocks. The ability to isolate the function in discrete units which can each 

1 8 be designed, evaluated and constructed separately promises to reduce the complexity of 

19 the overall system, especially at the point in time where a system needs to be fixed, 

20 modified or extended. The current technology of choice for implementing a services 

21 oriented architecture is to represent each of these blocks of function as a web service. 

22 Web Services 

23 Web services are a loose collection of specifications currently being standardized across 

24 the IT industry. In this technology, the blocks of function are referred to as web services. 

25 The web service specifications address how the blocks communicate and provide a means 

26 of describing the web service interface using Web Services Description Language 

27 (WSDL). WSDL is an extensible Markup Language (XML) based language for 

28 describing the services invocation syntax, error syntax and security along with many other 
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1 characteristics such as quality of service. The web services collection of specifications are 

2 intended to go beyond basic connection to cover transactional interactions, reliable 

3 delivery, and a method according to which multiple web services can be combined or 

4 composed into yet new web services with their own WSDL description. 

5 The most basic pattern of usage of a web service is for a service Consumer to request 

6 services from a service Provider. Information necessary to formulate the service request 

7 call is contained in the WSDL document associated with the service being called. The 

8 goal of the authors of these WSDL documents is that a Consumer that follows the 

9 specification will receive the correct response. There are many ways a client may 

10 discover the availability of a service and multiple ways the client may obtain the specific 

1 1 calling information recorded in the WSDL document. 

12 The two typical styles of interactions employed by web services are Remote Procedure 

13 Call (RPC) based and asynchronous or Document Literal (DocLit). In RPC style, the 

14 calling system invokes a function with optional parameters on the serving system. The 

15 serving system performs the function and returns results or an error to the calling system. 

16 At that point, the RPC call has completed. The DocLit style is somewhat different 

17 conceptually in that the relationship between service Consumer and service Provider is 

18 somewhat different. A DocLit interaction is initiated through a web services call that 

19 transfers a document (an information container) to the service Provider. The service 

20 Provider performs processing based on the document's origin, type or content and then 

21 makes a subsequent web services call transferring a responsive document containing the 

22 desired information to a web service Provider associated with the initiating node, or with 

23 some other node. This is sometimes referred to as document passing style. One skilled in 

24 the art will immediately recognize that any set of function implemented in DocLit style 

25 may be reproduced with an RPC implementation and vice versa. Of course, the overall 

26 system characteristics such as race conditions and performance can be quite different in 

27 the two styles. 
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1 The web services specification materials describe a repository that can be used to store 

2 web services, their WSDL description and other identifying information that can be used 

3 to locate, select and ultimately use a particular supplier of a web service. 

4 One familiar with the history of distributed computing will recognize many similarities 

5 between web services and earlier technologies such as Common Object Request Broker 

6 Architecture (CORBA) where Interface Definition Language (K)L) plays a role similar to 

7 WSDL for web services. CORBA is currently used in the industry, but has not achieved 

8 the level of adoption necessary to converge the IT industry on a universally accepted 

9 interface technology. 

10 Authentication of a user: Many computer programs require the end-user or a program 

1 1 representing the end-user to prove the identity of the user prior to allowing the user access 

12 to the program's capabilities. The simplest method of this is a logon based on a userid 

1 3 and secret password. Other methods include providing a certificate of identity generated 

14 by a third party and challenges based on shared secret knowledge or in possession of a 

15 computing device that is (approximately) synchronized with the computer issuing the 

16 challenge and which can generate a response using an algorithm that depends on the time 

17 of day or a combination of the time of day and the challenge. The proof of identity is a 

1 8 necessary element of secure computing and will often be a necessary function in 

19 establishing a relationship between a Consumer and a Provider, but it does not by itself 

20 validate that the user or programs representing the user can effectively engage with a 

21 Provider; i.e. that the Customer is capable of sending a correct transmission to the 

22 Provider. 

23 Certification of network equipment, including computer programs: Since the advent of 

24 telephone networks, network operators have required that, prior to equipment being 

25 connected to the network, it must have been proven that the equipment does not present 

26 any danger or threat to the network and that the equipment correctly implements the 

27 network protocols. More recently this requirement has been extended to functionality 
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1 that is implemented through software. This proof is produced by off-line exercising of 

2 the equipment or software against certified test equipment and software that simulates the 

3 behavior of the real network. These tests are generally conducted once when a new 

4 product is ready for service and are not repeated during the lifetime of that version of the 

5 equipment. Moreover, if the equipment is produced in volume, the testing is applied only 

6 to a small number of units. The design is then homologated. This procedure is performed 

7 off-line and only once. 

8 Verification of input accuracy: For complex or critical requests from a Consumer of 

9 services, for example financial transfer services between banks, it is desirable to verify 

10 that the Consumer has specified a valid request. For example, in a financial transfer 

1 1 system a Test function may exist in which the source and destination accounts, the 

12 currency and amount to be transferred, and the effective date of the transfer are entered 

13 together with a Test encryption key. This Test request is transmitted to the destination 

14 bank, which recognizes from the key that it is a test. The destination bank verifies that 

1 5 the accounts, currency, and effective date are valid, and if all is correct, notifies the 

16 Consumer that such a request, if submitted with a real key would be accepted for 

17 processing. Such a validation method proves the ability of the Consumer to correctly 

18 specify a simple request in which the parameters are essentially independent and 

1 9 knowably correct values. 

20 Ordering merchandise from an on-line store is similar, in that the customer clicks on the 

21 displayed stock number and enters a credit card number, which has a specified number of 

22 digits and a checksum. The vendor checks that the number of digits is correct and 

23 verifies the checksum value. 

24 However in the kinds of transactions envisaged for Web Services, complex dependencies 

25 exist among the parameters. As a trivial example, when making a request for nuts and 

26 bolts it will often be the case that the quantities of each will be the same. In a more 

27 complex case, the request may concern a large Bill of Materials with similar trivial 
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1 dependencies among the individual parts but with the option for the Provider to substitute 

2 after-market parts for OEM parts. Here the ability of the Consumer to generate a correct 

3 input and to process the response from the Provider are qualitatively different from 

4 simple verification of input accuracy. 
5 

6 Verification of operator capability: For reasons of safety, vehicles and heavy equipment 

7 may require the operator to perform a certain task before he or she is allowed to start 

8 operations. This verification is intended to prove that the operator is physically and 

9 mentally capable of performing the operations needed to safely operate the vehicle or 

1 0 equipment. In particular it is intended to detect whether the operator is tired or under the 

1 1 influence of alcohol or other drugs. Typically such tasks require some mental/physical 

12 coordination in the form of a kind of game or some mental capacity to perform a 

13 calculation or logical problem. While such verification can determine whether the 

14 operator is generally mentally and physically capable of performing the kinds of tasks 

15 needed to operate the equipment, it does not verify that the operator can in practice 

16 operate the equipment. A computer analogy might be to provide a verification method 

17 that allowed a Provider to access the system management status of the computer on which 

18 the Consumer program is running. This could determine that the computer itself is 

19 operating, but it is not sufficient to confirm that the Consumer can in fact correctly 

20 operate with the Provider. 

21 Service Level Agreement (SLA) 

22 A service level agreement or SLA is a means for specifying and quantifying the level of 

23 service offered by a service Provider. Indeed, a service level agreement could be a written 

24 document or an electronically readable specification for various characteristics of the 

25 service. For instance, a service level agreement may specify the level of availability of a 

26 service such as available at least 99.95% of the time. Another example of a service level 

27 agreement component would be a response time specification such as - response will be 

28 provided to every query within 5 seconds at least 98% of the time during which the 

29 service is up. Service level agreements can be very complex and can even place 
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1 requirements on the Consumer of the service. Service level agreements are limited in that 

2 they only assert capabilities, and may go on to describing an executable procedure for 

3 measuring compliance based on mutually accepted primitive definitions and concepts. 

4 In order for service Providers to more easily conform to SLA agreements, methods of 

5 monitoring systems to ensure performance have been developed. US Patent 5893905, 

6 entitled "Automated SLA performance analysis monitor with impact alerts on 

7 downstream" teaches a system and method for monitoring the performance of selected 

8 data processing jobs, comparing actual performance against the Service Level Agreement 

9 (SLA) to which each monitored job belongs, identifying discrepancies, and analyzing 

10 impacts to other jobs in a job stream. This allows more effective compliance with SLA 

1 1 terms. 

12 PROBLEMS WITH THE PRIOR ART 

13 Test methods today allow users to verify the function of the service Provider. What is 

14 needed is a method for services to validate that Consumers have the ability to properly 

15 use the service. Further, what is needed is the ability to validate this ability at any time, 

16 especially when changes in hardware and software make it more likely that problems may 

17 occur. 

18 RPC and object oriented technologies require prior agreement as to implementation 

19 techniques; these are tight couplings. What is needed is loose bindings to allow ad hoc 

20 service usage and application integration 

21 SLAs cover the service Provider commitments but do not require any compliance by the 

22 Consumer of the service. Some services require appropriate use; further some services 

23 may be more economically supplied to those subscribers who are able to appropriately 
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1 take related actions such as problem determination, and reporting. 

2 The reliability, viability and effectiveness of a service Provider can depend on how the 

3 service is used by the Consumers of the service. There are many causes for service failure 

4 that derive from improper usage of the service rather than from a failure within the 

5 service. Additionally, a service Provider may make changes which affect the behavior of 

6 the service, causing failure. What is needed is a way for Providers to validate the ability 

7 of a user to use the service. 

8 SUMMARY OF THE INVENTION 

9 The invention relates to a method, apparatus and system by which a computerized service 

10 Provider can require the service Consumer to test and confirm, or validate, their ability to 

1 1 correctly use the service. 

12 A feature of the invention is the receipt of test data by the Consumer that the Consumer 

1 3 operates on to generate a Consumer output that is validated by the Provider. 

14 Another feature of the invention is a response by the Provider to the Consumer indicating 

1 5 the result of the assessment by the Provider; e.g. pass/fail. 

16 Yet another feature of the invention is a response by the Provider to the Consumer 

17 indicating a contingent result of the assessment by the Provider; e.g. permission to place 

18 service requests for a period of time. 

19 Yet another feature of the invention is the supply by the Provider to the Consumer of test 

20 data to be used in generating the Consumer's output. 

21 Yet another feature of the invention is a linking by the service to other services that it 
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uses, so that the validations can be "chained" to allow validation end to end. 



2 BRIEF DESCRIPTION OF THE FIGURES 

3 The foregoing and other objects, aspects, and advantages will be better understood from 

4 the following non limiting detailed description of preferred embodiments of the invention 

5 with reference to the drawings that include the following: 

6 Figure 1 : WSDL service invocation 

7 Figure 2: Service Oriented Architecture 

8 Figure 3: Call flow of the inventive method 

9 Figure 4: Flowchart of elements of the method for a service Provider 

10 Figure 5: Flowchart of the elements of the method for a service Consumer 

1 1 Figure 6; Multiple chained service Providers 

12 Figure 7: Call flow of the inventive method, with complex validation 

13 Figure 8: Business models supported by the invention 

14 DETAILED DESCRIPTION OF THE INVENTION 

15 Figure 1 illustrates a common method for using the web services specifications for 

16 interaction between a service Consumer and a service Provider. A computational block 

17 (105) is to be made available as a web service. This is accomplished by deploying a web 

18 service interface (1 10) and making a WSDL description of the interface (1 1 5) available to 

19 potential service Consumers. At this point, the web service is said to have been deployed. 
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1 Through a variety of potential methods (one of which will be described below) the service 

2 Consumer (120) obtains a copy (125) of the WSDL document (1 15) and uses it to 

3 configure the web services client (130) with information about the service call format and 

4 the service location. This example describes the RPC style of interaction. Once the client 

5 is configured, a call originating within the service Consumer (120) will be processed by 

6 the web services client stack (130) which will format the information and direct the call 

7 to the web services Provider interface (110). The web services Provider interface (110) 

8 will receive the information, convert it to a suitable format and then launch the indicated 

9 function within the computational block (105). Once the computation has completed the 

1 0 result (or error information) will be appropriately packaged and returned by the deployed 

1 1 interface (1 10) to the web services client (130) which will perform any necessary 

12 unpacking of the information and provide it to the service Consumer (120), thereby 

1 3 completing the RPC invocation. 

14 Figure 2 illustrates the described characteristics of a services oriented architecture. Not all 

15 of the elements described here are necessary for an implementation to qualify as a 

16 services oriented architecture. In particular, there are a variety of discovery mechanisms 

17 that could be employed, including an out-of-band process that provides appropriate 

1 8 information about services to the client implementation or programmer. 

19 Service Provider 1 deploys his service consisting of a WSDL description (205) 

20 computational block (206) and interface 207 as illustrated in Figure 1. Then Service 

21 Provider 1 or his agent publishes a WSDL description for service interface 207 (possibly 

22 with other descriptive information) in a discovery mechanism (230) which will frequently 

23 be built to the Universal Description, Discovery and Integration (UDDI) specification. 

24 Subsequently, Service Provider 2 deploys his service consisting of a WSDL description 

25 (215) computational block (216) and interface 217 as illustrated in Figure 1 . Then Service 

26 Provider 2 or his agent publishes a WSDL description for service interface 217 (possibly 

27 with other descriptive information) in discovery mechanism (230). 
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1 When service Consumer (221) decides to use a service it can search the discovery 

2 mechanism (230) for a service with the desired characteristics, then use the stored WSDL 

3 (either 208 or 218 depending on the service chosen) to configure the communications 

4 interface (220) (as illustrated in figure 1) for requesting service from the chosen service. 

5 One of the manifest advantages of a properly designed and implemented service oriented 

6 architecture is that an equivalent service can be substituted for a currently used service 

7 with little change to anything but the communications interface, and that change should 

8 be limited to configuring or modifying the interface to use the information found in the 

9 appropriate WSDL document. 

10 Figure 3 shows a block diagram illustrating the call flow, denoted generally by the 

1 1 numeral 300, of the inventive method. After service Provider (301) has deployed one or 

12 more web service interface(s) that can process data and provide validation data, and after 

13 service Consumer 330 has created a service client that is configured to interact with 

14 Provider (301) then the illustrative call flow shown in the bottom half of figure 3 can 

15 begin. (Note: the two functions of providing validation data and consuming second 

16 validation data could be combined into a single web service that, through appropriate 

17 semantic and/or syntactical means, can distinguish between the two functions. 

18 Alternatively, the two functions could be provided as separate web services.) The flow is 

19 initiated in step (335) in which service Consumer 330 requests the first validation data 

20 (indicated by arrow 340) from service Provider 301 . In step 342, service Provider (301) 

21 generates or retrieves the first validation data. In step 345, the first validation data is 

22 transmitted to the service Consumer (330). Though figure 3 (300) illustrates this 

23 interaction in the form of an RPC style web services interaction, this illustrative sequence 

24 could be realized by the equivalent set of Doc-Lit asynchronous messages. 

25 In step 350, the service Consumer (330) receives the first validation data and operates on 

26 or performs whatever processing the Consumer is constructed to perform. The result of 

27 this processing is herein referred to as the second validation data. 



YOR920030272US1 



1 The first validation data may be chosen with great flexibility. For example, they may 

2 include a catalog or price list of offerings by the Provider. They may also include a small 

3 amount of data chosen to make the process easy for the Consumer, or anything in 

4 between. The first validation data may include one or more of random numbers, reserved 

5 invariant data, reserved variant data, invalid data (e.g. nonexistent part numbers intended 

6 to validate error processing), data indicative of processing to be performed for validation 

7 response and others. 

8 The process of making the first validation data available to the Consumer may include 

9 many methods such as publishing first validation data to the web, making data available 

10 for download, transmitting a pointer to data, providing a removable media, creating one 

1 1 time valid first validation data and creating personalized first validation data. 

12 An example of the intended service is a parts ordering service (e.g. of a hardware store to 

13 a hardware distributor); the first validation data may contain hardware item numbers. The 

14 Consumer is expected to construct from this first validation data a sample order of parts 

15 from each category available. The constructed order may be the second validation data. 

16 This is very different from current e-business methods such as on-line ordering from a 

17 vendor such as Amazon. In today f s ordering methods, an order is placed and the 

18 validation of the order or credit card may consist of checking that the catalog numbers 

19 are ones that appear in the catalog and that the credit card number is valid. Such a 

20 process does not allow the Provider to evaluate the user's ability to fully use the service 

2 1 (e.g. register reviews). 

22 Referring back to Figure 3, in step (360) the second validation data is transmitted to the 

23 service Provider (301). In step (362) the service Provider processes the second validation 

24 data and in step 365 (optionally) acknowledges the completion of the processing. Once 

25 again, the final web service interaction is represented as an RPC interaction, and could 

26 equally be achieved by one or more asynchronous Doc-Lit style interactions. Indeed, in 

27 the Doc-Lit interaction, the acknowledgement (step 365) could be directed to a different 
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1 entity from the service Consumer (330). 

2 Figure 4 shows a flowchart of the elements of the inventive method, denoted generally by 

3 numeral 400, that are performed by a service Provider. In step 410, the service Provider 

4 makes available an service invocation specification. In one embodiment, the 

5 specification is made available through a web services interface. In this case, the service 

6 Provider may be registered via a Universal Description, Discovery and Integration 

7 (UDDI) directory, and use WSDL to provide the service specification. Details on UDDI 

8 are available at http://www.uddi.org/specification.html. The service invocation 

9 specification provides enabling detail on how to access the service. In other 

10 embodiments, the specification may be made available through a web page, as machine 

1 1 readable material on a removable media such as a diskette, CD-ROM, DVD or zip disk, 

12 published in a journal, or any other convenient method. The invocation may be available 

13 generally, or may be available to a subset of the general public or any collection of one or 

14 more potential service Consumers. 

15 In general, the specification may include criteria that the Provider requires to be met 

16 before providing service. The criteria according to the invention may be very flexible. 

17 For example, one or more answers or elements of the second validation data may be 

18 required to be correct. One answer may be required to be correct, with incorrect answers 

19 on other points resulting in a different level of service and/or different cost, rather than 

20 denial of service. The answers or responses may be within a range of acceptability rather 

21 than according to a binary True/False approach. 

22 As one example, the Provider may (temporarily) accept all responses to the first 

23 validation data, i.e. effectively suspending the validation process, in order to increase 

24 business or for other reasons. 

25 We continue to step 420. In this step, the service Provider provides access to first 

26 validation data. Access may be provided by any of: publishing first validation data to the 
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1 web, making data available for download, transmitting a pointer to data, providing a 

2 removable media, creating one time valid first validation data and creating personalized 

3 first validation data. 

4 This data is provided along with the invocation specification of step 410 so that a service 

5 Consumer may exercise the service Consumer's process on the validation data, in a 

6 manner consistent with the service invocation specification. The data provided may be 

7 the same for all service Consumers, e.g. generally available, or may be specific to the 

8 service Consumer, e.g. available upon request and customized. In step 430, the service 

9 Provider receives second validation data from a service Consumer, such data expected to 

10 be responsive to the validation data and invocation specification of steps 410 and step 

1 1 420. This second validation data is used by the service Provider to evaluate the capability 

12 of the service Consumer to properly consume the service. The service Provider may 

1 3 optionally acknowledge the receipt of the second validation data. 

14 This may be understood from the following two examples: 

15 A service Provider HD is a hardware parts distributor, and receives parts from a multitude 

16 of suppliers. The catalogue of parts from HD is therefore somewhat variable. HD wishes 

17 to minimize the disruption of receiving invalid part numbers on orders from HD's 

18 customers, these customers being local hardware retail stores. In order to receive some 

19 assurance that the local hardware retail stores can formulate a good order, HD publishes a 

20 web service for such orders, including a validation service (step 410). The validation 

21 service makes available a validation data catalogue with bogus part numbers to 

22 prospective hardware store customers. The hardware store customers must use the 

23 validation data catalogue, provide an order in accordance with the invocation 

24 specification, and send the order to the hardware distributor HD (received in step 430). If 

25 the order is well formulated with appropriate volumes, contents, shipping, etc., then HD 

26 will allow service to be provided. Note that many possible orders can be constructed 

27 from the catalogue. In this example, there is no specific order required — simply a valid 

28 order must be constructed by the service Consumer, and appropriately transmitted to the 
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1 service Provider. 

2 A second example concerns a network service. A network service Provider may provide a 

3 multi-network spanning multi-modal conferencing service. In order to minimize help 

4 desk costs, and maximize availability, this service Provider wishes to ensure that 

5 prospective clients are able to assist in problem determination. In this example, the 

6 service invocation details are published, along with trouble report ticket specifications 

7 (step 410). On service Consumer request, network services with errors injected are 

8 provided to the service Consumer (e.g. validation data per step 420). The service 

9 Consumer must construct appropriate trouble reports and send them to the service 

10 Provider (received in step 430). In this fashion, the service Provider can reduce the risk 

11 of improper error reporting in regards to the service, and presumably keep costs of 

12 problem determination and repair at a minimum. 

13 We continue with step 440 of the method. In this step, the service Provider receives an 

14 actual request for service from a service Consumer. In step 450, the service Provider 

15 determines whether the validation data received from the service Consumer in step 430 

16 are acceptable. If so, the service is provided in step 460. If not, the Provider executes step 

17 470. In either case, the process ends at step 480. Note that this step 450 may be 

18 performed before step 440 rather than afterwards. Optionally, the results of this 

19 determination may be transmitted to the service Consumer. 

20 In some embodiments, second validation data which had been acceptable at one point in 

21 time, may not be acceptable at a later time. Time since receipt of second validation data, 

22 software or hardware update status, calendar date, method of access, scope of service 

23 requested, or other criteria may be used to determine whether the second validation data 

24 received from the service Consumer is acceptable. 
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1 If the data is acceptable, we continue to step 460, and provide the requested service. Note 

2 that additional processing may occur before service is provided. In some embodiments, 

3 the service Provider may require interaction with the Consumer, may require interaction 

4 with a credit bureau to check service Consumer credit rating, etc. Following step 460, the 

5 method may optionally loop back to step 440, and the service Provider may receive 

6 another service request. Alternately, the method ends with step 480 as we exit. 

7 If step 450 determines that the second validation data is not acceptable, we continue to 

8 step 470 and perform service denial processing. This processing may include but is not 

9 limited to transmitting an indication of refusal of service, transmitting an indication of 

10 requirement of new second validation data, publishing a notice of service refusal, 

1 1 transmitting an indication of refusal to a third party, transmitting an indication of 

12 requirement of new second validation data to a third party. Optionally, the method 

13 continues from this step to step 410, or step 420, or step 430. Otherwise, we end the 

14 method at step 480 and exit. 

15 Figure 5 shows a preferred embodiment of the method for a service Consumer. The 

16 method, denoted generally with the numeral 500, begins with step 510, where the service 

17 Consumer receives an indication from the service Provider of a need to validate the 

18 service Consumer's ability to properly consume the service before service is provided. 

19 Prior to this step, the service Consumer may have recently requested service (i.e. the 

20 indication of a need to validate may be in response to a request for service). Alternately, 

21 the service Provider may send such an indication periodically, or upon change to the 

22 invocation specification, or upon change to some other aspect of the service. If the 

23 indication was not in response to a request for service, then presumably the service 

24 Provider has had a business relationship of some sort with the Consumer thereby enabling 

25 the Provider to send such an indication. 

26 We continue to step 520. In this step, having received the request to validate, the service 

27 Consumer requests first validation data. While we do not show a step of the service 
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1 Consumer receiving the invocation specification for the service, it is understood that prior 

2 to the request for first validation data, the service Consumer may optionally have 

3 requested and received the invocation specification. Further in this step, the service 

4 Consumer receives said first validation data. The data may be received from the service 

5 Provider, or from a third party responsive to the request. 

6 Responsive to the first validation data, and according to the understood service invocation 

7 specification, the user service Consumer determines (or generates) second validation data 

8 in step 530. That is, the service Consumer applies the service consuming process to the 

9 first data and provides second data in accordance with the service. Note that while this 

10 method discusses a single step of interaction between the parties, it is understood that 

1 1 there may be multiple steps of interaction required to complete the determination of the 

1 2 second validation data. 

13 We continue in step 540, where the service Consumer provides the second validation 

14 data. This data may be provided to the service Provider, or to a third party as indicated by 

1 5 the service invocation specification. 

16 In step 550, the service Consumer receives an optional response from the Provider to the 

17 second validation data. This response may be an acknowledgement, or an indication of 

18 the validity of the data as received. If no response is expected or received, the user may 

19 proceed directly to step 580. Alternatively, if a response is expected but not received, the 

20 user may proceed directly to step 570. 

21 In step 560, the service Consumer evaluates whether the second validation data was 

22 acceptable as indicated by the response. If the data was acceptable, the service Consumer 

23 may continue to request service in step 580. Note that this step may follow 560 with any 

24 degree of elapsed time. That is, the service Consumer may rapidly request service, or not. 

25 Such a service request may wait for Consumer need, scheduled request, etc. 
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1 If the second validation data was not acceptable as indicated by the response, we proceed 

2 to step 570, and the service Consumer may perform error processing. This processing 

3 may consist of logs, error messages, alerts and notifications, alarms, revalidation 

4 attempts, etc. 

5 The method completes after these steps. 

6 The foregoing example illustrates that the invention is not confined to one model of the 

7 relationship between the Provider and the Consumer. At one extreme, a powerful 

8 Consumer may specify formats and other criteria and require its vendors to conform to 

9 that specification as a condition of doing business. At another extreme, a large vendor 

10 may require its customers to conform to its method of accepting orders. Yet other 

1 1 relationships may have a mixed model in which both sides specify aspects of the 

12 transactions. 

13 Figure 6 shows an example of the invention as used in conjunction with multiple service 

14 Providers in a relationship, denoted generally with the numeral 600. In this example, a 

15 service Consumer (not shown) obtains service provided by a service Provider SP1 noted 

16 as block 610, which itself obtains services from other service Providers SP2 (block 620), 

1 7 SP3 (block 630), and SP4 (block 640). 

18 This example may be better understood by reference to a supply chain application. 

19 Assume that SP1 of block 610 is a bundler of goods (e.g. a hardware parts distributor) 

20 obtaining these goods from SP2 of block 620 (a nails manufacturer), SP3 of block 630 (a 

21 screw manufacturer), and SP4 of block 640 (a bolt manufacturer). SP2 makes available an 

22 invocation specification (not shown) and first validation data FVD2, block 625. SP3 

23 makes available an invocation specification (not shown) and first validation data FVD3, 

24 block 635. SP4 makes available an invocation specification (not shown) and first 

25 validation data FVD4, block 645 . This information may or may not be made available to 

26 the general public, but is made available to service Provider SP 1 , block 610. In our 
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1 supply chain example, first validation data FVD2 consists of sample part numbers of 

2 nails. First validation data FVD3 consists of sample part numbers of screws. First 

3 validation data FVD4 consists of sample part numbers of bolts. The invocation 

4 specification details how to construct acceptable orders. Service Provider SP1 of block 

5 610 offers services to a hardware store. SP1 makes available an invocation specification 

6 (not shown) and first validation F VD 1 . 

7 A user of SP1 services (e.g. a local hardware store) requests validation. In response to the 

8 request for validation, SP1 requests access to first validation data from SP2, SP3, and 

9 SP4. SP1 obtains access to this data, and constructs its own first validation data FVD1. 

10 In our example, SP1 receives sample part numbers of screws, bolts and nails, and adds to 

1 1 these a part number for a free apron. The information is further processed (e.g. translated 

12 to Spanish). This is used to construct SP1 first validation data, that is FVD1 of block 

13 615. Access to FVD1 is provided to the hardware store requesting service. This first 

14 validation data represents a one time collection of items that may be ordered to validate 

1 5 the hardware store's usage of the service. 

16 The user of the service (the hardware store) must then create an order from among these 

17 items and return it to SP1 as second validation data to validate that they can indeed create 

18 properly structured orders from available parts. SP1 receives the order, examines it to 

19 conclude whether or not it is ok, and may optionally confirm back to the user. SP1 may 

20 or may not provide second validation data to SP2, SP3, SP4 depending on the structure of 

21 their validation process. This validation can be for free or for a fee. 

22 Let us take a second example from this figure. SP2, SP3, SP4 may be gateways to 

23 disparate networks, and SP1 a bundler of services from among those networks. The 

24 validation may be in exercising a complex network service such as multimodal 

25 conferencing among disparate endpoints. Validation may be for the purpose of validating 

26 ancillary management such as billing and problem determination. 
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1 In order to verify that the user can properly participate in problem management, the 

2 validation scenario may be as follows. Following the SP1 invocation specification (not 

3 shown), the user requests of SP1 a service validation and provides addresses of 

4 participating devices. SP1 then requests first validation data of downstream Providers 

5 SP2, SP3 and SP4, providing the relevant addresses of participating devices. SP2 makes 

6 available an invocation specification (not shown) and first validation data FVD2, block 

7 625, consisting of errors injected into communications to devices attached to the SP2 

8 network. SP3 makes available an invocation specification (not shown) and first 

9 validation data FVD3, block 635, consisting of errors injected into communications to 

10 devices attached to the SP3 network. SP4 makes available an invocation specification 

1 1 (not shown) and first validation data FVD4, block 645, consisting of errors injected into 

12 communications to devices attached to the SP4 network. SP1 aggregates error 

13 indications received in its elements associated with the device addresses, and provides 

14 these indications to the service Consumer. In accord with the service invocation (not 

15 shown), the service Consumer must create an appropriate problem report as second 

1 6 validation data and provide it to SP 1 . Presumably complete and accurate creation of such 

17 a problem report will allow SP1 to judge that the service Consumer will be a low cost 

1 8 customer to maintain, since they are able to fully participate in problem determination. 

19 While these examples show a service Provider hierarchy that is a single level deep, it is 

20 understood by those skilled in the art that the hierarchy may be many levels deep. That is, 

21 service Providers discussed may themselves obtain services from other service Providers 

22 - SP2 may receive services from SP5 and SP6 (not shown). SP5 may receive services 

23 from SP7 (not shown), and so on. 

24 Figure 7 shows a block diagram illustrating a more complex validation sequence. After 

25 service Provider (701) has deployed web service interfaces that provide validation data 

26 and process functional data (703 and 706 respectively). And after service Consumer 730 

27 has created a service client that is configured to interact with Provider (701) interfaces, 

28 then the illustrative call flow shown in the bottom half of figure 7 can begin. (Note: the 
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1 two functions of providing validation data and consuming second validation data could be 

2 combined into a single web service that, through appropriate semantic and or syntactical 

3 means, can distinguish between the two functions. Alternatively, the two functions could 

4 be provided as separate web services as shown here.) The flow is initiated in step (735) in 

5 which service Consumer 730 requests the first validation data (via 740) from service 

6 Provider interface (703). In step 742, service Provider (701) generates or retrieves the 

7 first validation data and returns the result. In step 745, the first validation data is 

8 transmitted to the service Consumer (730). Though figure 7 illustrates this interaction in 

9 the form of an RPC style web services interaction, this illustrative sequence could be 

10 realized by the equivalent set of Doc-Lit asynchronous messages. In step 750, the service 

1 1 Consumer (730) receives the first validation data and performs whatever processing the 

12 Consumer is constructed to perform. The result of this processing is herein referred to as 

13 the second validation data. In step (760) the second validation data is transmitted to the 

14 service Provider (701) via service interface 706. In step (762) the service Provider 

15 processes the second validation data and in step 765 returns the processed result. Once 

16 again, the final web service interaction is represented as an RPC interaction, and could 

17 equally be achieved by one or more asynchronous Doc-Lit style interactions. Note: the 

1 8 processing results (step 765) could be directed to a different entity (i.e. not the initiating 

19 service Consumer 730). In step 770 the processed results of the second validation data are 

20 further processed through the requesting service (730) normal functional path. In step 

21 (780) these results are sent via the validation interface to service Provider (701). 

22 Responsive to the returned results, service Provider (701) returns an acknowledgement 

23 (785) to the requester (730) (Note, here again the acknowledgement could be directed to 

24 a different entity). The acknowledgement may contain information indicative of the 

25 outcome of the processing performed in step (782), thereby potentially providing the 

26 client implementation an indication of which processing steps to perform subsequently. 

27 BUSINESS MODELS SUPPORTED BY THIS INVENTION 
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Figure 8 illustrates the business models supported by this invention. 



2 In this invention the concept of service is quite general The examples show services that 

3 are either a) actions that can be completely executed by computing processes carried out 

4 by moving electrons or photons; or b) an action taking place outside electronic apparatus 

5 that can be invoked by the execution of computing processes. An example of the first 

6 type of action is the translation of a document from one human language to another 

7 human language. An example of a the second type of action is the dispatch via a 

8 computer action of a 5 ton roll of paper to be cut, packaged, and shipped to meet a 

9 customer's specification. A service need not even have an immediate effect on the 

10 customer, for example updating a database entry. 

1 1 The simplest case we consider is a single Consumer 810 connected to a single Provider 

12 8 1 5 . In many cases a program of the kind we are considering will be both a Consumer 

13 820 and a Provider 825. Its Consumer interface will be connected to the Provider 

14 interfaces of one or more other programs and its Provider interface will be connected to 

15 the Consumer interfaces of one or more other programs. It is even conceivable that two 

16 such programs can be connected on both their Consumer and Provider interfaces. 

17 An important benefit of Web Services is the ability of a Consumer of service to connect 

18 simultaneously to one or more Providers of services. The Consumer 830 may selectively 

19 direct different requests to different Providers 835 or may invite all current Providers 835 

20 to compete on a single request. Likewise a Provider of Service 845 may be connected to 

2 1 one or more Consumers of Service 840. 

22 The vision of Web Services is the assembly of networks of business processes, 

23 implemented as computer programs, in which there are several or potentially many 

24 Consumers 820 and Providers 825 connected together 850. While this invention deals 

25 with the validation process between a single Consumer and a single Provider, it can also 

26 be applied sequentially over such a network 850 of business processes to provide end-to- 
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1 end validation. 

2 From the point of view of a Consumer of services, a service Provider presents a single 

3 interface. However, it is possible that what appears to be a single, monolithic service is 

4 in fact a compound service provided by an encapsulated network of sub-Providers 855. 

5 While this invention deals with the validation process between a single Consumer and a 

6 single Provider, it can also be applied recursively over such hierarchies of Process, sub- 

7 Processes, sub-sub-Processes, and so forth. 

8 Although the invention is illustrated with some selected examples, many other 

9 embodiments may be included within its scope. 

10 For example, the first validation data may comprise random numbers, reserved invariant 

1 1 data, reserved variant data, invalid data (e.g. nonexistent part numbers intended to 

12 validate error processing), data indicative of processing to be performed for validation 

1 3 response and others. 

14 The second validation data may comprise a checksum, a string of checksums, an array of 

15 data types responsive to the validation data, an order for service and others. 

1 6 The validation service may be provided to the Consumer without charge. Alternatively, 

17 the Provider may charge for validation after an initial threshold amount - i.e. extra 

18 validation services would be billed to the Consumer. The Provider may use the results of 

19 a validation in other ways than simply granting on denying service. For example, the 

20 Provider may charge extra for providing service if the validation indicates that it will cost 

21 more to service this Consumer. As a variation, the Provider may charge a standard rate 

22 for one of a family of services for which the Consumer has qualified and extra for other 

23 services for which the Consumer has not qualified. 

24 The notice sent to a successful Consumer by a vendor may include a limited time period 
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1 for which access to services is permitted, a scheduled time for reconfirmation, a subset of 

2 services that are permitted, one of multiple permission status (e.g. revalidate on demand, 

3 revalidate on Tuesday), etc. 

4 The step of distributing the data or criteria to which the Consumer must conform may 

5 include publishing a web service specification, making available a specification for 

6 download, making available a machine readable specification for download, transmitting 

7 a pointer to a specification, providing a removable medium (e.g. CD ROM) of a 

8 specification and others. 

9 The step of providing access to first validation data may include publishing first 

10 validation data to the web, making data available for download, transmitting a pointer to 

1 1 data, providing a removable medium, creating one time valid first validation data, 

12 creating personalized first validation data and others. 

1 3 Variations described for the present invention can be realized in any combination 

14 desirable for each particular application. Thus particular limitations, and/or embodiment 

15 enhancements described herein, which may have particular advantages to a particular 

16 application need not be used for all applications. Also, not all limitations need be 

17 implemented in methods, systems and/or apparatus including one or more concepts of the 

18 present invention. 

19 The present invention can be realized in hardware, software, or a combination of 

20 hardware and software. There may be some elements of the inventive system located in 

21 equipment controlled by the Provider and other elements located in equipment controlled 

22 by the Consumer. The separate elements may be supplied by different vendors (provided 

23 they are compatible). An embodiment of the present invention can be realized in a 

24 centralized fashion in one computer system, or in a distributed fashion where different 

25 elements are spread across several interconnected computer systems. Any kind of 

26 computer system - or other apparatus adapted for carrying out the methods and/or 
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1 functions described herein - is suitable. A typical combination of hardware and software 

2 could be a general purpose computer system with a computer program that, when being 

3 loaded and executed, controls the computer system such that it carries out the methods 

4 described herein. The present invention can also be embedded in a computer program 

5 product, which comprises all the features enabling the implementation of the methods 

6 described herein, and which - when loaded in a computer system - is able to carry out 

7 these methods. 

8 Computer program means or computer program in the present context include any 

9 expression, in any language, code or notation, of a set of instructions intended to cause a 

10 system having an information processing capability to perform a particular function 

1 1 either directly or after conversion to another language, code or notation, and/or 

12 reproduction in a different material form. 

13 Thus the invention includes an article of manufacture which comprises a computer usable 

14 medium having computer readable program code means embodied therein for causing a 

15 function described above. The computer readable program code means in the article of 

16 manufacture comprises computer readable program code means for causing a computer to 

17 effect the steps of a method of this invention. Similarly, the present invention may be 

18 implemented as a computer program product comprising a computer usable medium 

19 having computer readable program code means embodied therein for causing a function 

20 described above. The computer readable program code means in the computer program 

21 product comprising computer readable program code means for causing a computer to 

22 effect one or more functions of this invention. Furthermore, the present invention may be 

23 implemented as a program storage device readable by machine, tangibly embodying a 

24 program of instructions executable by the machine to perform method steps for causing 

25 one or more functions of this invention. 

26 An evaluation according to the invention may be done before initial use of the service, 

27 periodically to confirm continued use of the service and/or upon recognition of changes 
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1 made within the service. If the service itself uses other services, the validations can be 

2 "chained" to allow validation end to end. This invention does not require that the 

3 Consumer has the ability to test the Provider service. Such testing by the Consumer may 

4 or may not be provided in a system employing the invention. 

5 Use of this invention can therefore reduce problems experienced in operational use, can 

6 assist in problem determination, can reduce risk for future operation, can provide a means 

7 for the service Provider to provide a representation of its clients ability to correctly use 

8 the service (e.g. to a third party for certification, for insurance purposes, etc.) 

9 It is noted that the foregoing has outlined some of the more pertinent objects and 

10 embodiments of the present invention. This invention may be used for many 

1 1 applications. Thus, although the description is made for particular arrangements and 

12 methods, the intent and concept of the invention is suitable and applicable to other 

13 arrangements and applications. It will be clear to those skilled in the art that 

14 modifications to the disclosed embodiments can be effected without departing from the 

1 5 spirit and scope of the invention. The described embodiments ought to be construed to 

16 be merely illustrative of some of the more prominent features and applications of the 

1 7 invention. Other beneficial results can be realized by applying the disclosed invention in 

18 a different manner or modifying the invention in ways known to those familiar with the 

19 art. 

20 While the invention has been described in terms of selected embodiments, those skilled in 

21 the art will recognize that the invention can be practiced in various versions within the 

22 spirit and scope of the following claims. 
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